Code Review — PR #12 (.github)

Summary

Restores auto-add-to-project.yml as a reusable workflow, just one day after PR #11 removed the same file. The restored YAML is technically sound: dual triggers (workflow_call + direct issues/pull_request_target) are consistent with how this file was structured in PR #4, the action is SHA-pinned to a verified v1.0.2 tag, and permissions: {} correctly minimises the default GITHUB_TOKEN scope.

The main concern is process / decision rationale, not the YAML itself.

1. Verification

2. Findings

2.1 P1 — Reversal of PR #11 lacks rationale (process)

PR #11 (d5ab928, merged ~12 hours before this PR was opened) removed this exact workflow with an explicit, documented rationale:

Replace with GitHub org Projects native Auto-add workflow rule […]

• Zero Actions minutes consumed
• No PROJECT_TOKEN dependency
• Covers all org repos via a single project settings config
• Lower maintenance overhead

This PR's body says "Restore … consistent with the existing reusable pattern" but never addresses why the four bullets above no longer hold. Reviewers and future maintainers will hit this same question. Concretely:

• Is the org-level native auto-add rule failing for some event type (PRs from forks, draft PRs, transferred issues)?
• Did it not respect a project view filter you needed?
• Is this restoration only intended for a subset of repos that the native rule cannot cover?

Recommendation: add 2–3 sentences to the PR body (and ideally a comment near the top of the file) explaining the trigger for the reversal, so the next person reading git log does not have to re-derive the trade-off. Without this context the change looks like churn and the next maintainer is likely to remove it again.

2.2 P2 — Missing timeout-minutes (consistency)

Sibling reusable workflows in this repo set a job-level timeout, e.g. pr-merged-done.yml uses timeout-minutes: 10, and PR #6 explicitly hardened the notify workflows by setting timeout-minutes: 3. The new file does not set one and will fall back to GitHub's 360-minute default. While actions/add-to-project is fast, a transient hang on the GraphQL call could otherwise burn minutes on every issue/PR opened.

jobs:
  add-to-project:
    runs-on: ubuntu-latest
    timeout-minutes: 5    # add this

2.3 P2 — PROJECT_TOKEN dependency for direct triggers is undocumented

For the workflow_call path the secret is declared (secrets.PROJECT_TOKEN, required). For the direct issues: and pull_request_target: paths in this repo, the same name secrets.PROJECT_TOKEN is read — but now it must exist as a secret on the .github repository (or as an org-level secret made available to it). If it does not, the workflow fails silently from the perspective of anyone opening an issue here.

The header comment lists the caller-side example but does not mention the local-repo prerequisite. Suggest adding one line:

# Direct triggers in this repo also require the PROJECT_TOKEN secret to be
# configured on Mininglamp-OSS/.github (or as an org-level secret).

2.4 P2 — pull_request_target is safe here, but worth a defensive comment

pull_request_target runs in the context of the base repo with full secret access on PRs from forks. The reason this is safe in this workflow is that no PR code is ever checked out or executed — only the upstream actions/add-to-project is invoked, with PROJECT_TOKEN and a static project URL. A future contributor who adds an actions/checkout step here (e.g. to enrich the project item with PR metadata from the PR's own files) would silently re-introduce the classic pwn-request vector.

Suggest a short pinned comment so the constraint is visible at the point of edit:

# pull_request_target is used so we can write to the org project from forks.
# DO NOT add `actions/checkout` of the PR ref here — would expose PROJECT_TOKEN
# to untrusted code.

2.5 Nit — Reusable workflow naming inconsistency

Sibling reusable workflows include the suffix (Reusable) / (reusable) in name::

• name: Issue Welcome (Reusable)
• name: Octo CI Status (reusable)
• name: Octo Issue Feed (reusable)
• name: Octo PR Feed (reusable)

This file uses name: Auto add to project. Minor, but the prior version was also unsuffixed, and fixing it now keeps the Actions UI listing readable.

3. Recommendations

In priority order:

1. (P1) Add rationale to the PR body explaining why the native org-level Auto-add rule introduced in PR #11 is being supplemented/replaced by this Actions-based path.
2. (P2) Add timeout-minutes: 5 to the add-to-project job to match the hardening pattern used elsewhere in this repo.
3. (P2) Document the PROJECT_TOKEN requirement for direct triggers in the file header.
4. (P2) Add an inline warning about not introducing actions/checkout under pull_request_target.
5. (Nit) Rename name: to Auto add to project (reusable) for consistency with the other reusable workflows.

4. Additional observations

• The PR description says "Per-repo caller workflows for all 8 sub-repos will be added in separate PRs after this is merged." Until those land, this PR has no observable behavioural effect on any repo other than .github itself. That's fine for scope, but worth flagging in the PR body so reviewers don't expect immediate org-wide effect after merge.
• Consider whether the org-level native auto-add rule (mentioned in PR #11) should be disabled once the reusable workflow path is live across the 8 sub-repos. Otherwise both paths will run in parallel; actions/add-to-project is idempotent (adding an already-present item is a no-op), so this is not a correctness bug, but it doubles the latency to "appear on the board" perception, and burns Actions minutes that PR #11 was deliberately trying to save.

Code Review — PR #12 (.github)

Summary

All five concerns from the prior review on d2419134 have been addressed in head 3c0e4be. The restored reusable workflow is technically sound, follows the same shape as sibling reusable workflows in this repo, and pins actions/add-to-project to a verified commit hash.

1. Verification of prior-review fixes

2. Independent verification

3. Findings

No blocking issues. One minor observation, not blocking:

3.1 Nit — project-url is hard-coded, not an input

The reusable workflow always writes to https://github.com/orgs/Mininglamp-OSS/projects/2. That matches the stated design intent ("a single, centrally maintained automation"), so this is fine for the immediate goal. If a future sub-repo ever needs to land in a different project (e.g. a private security project, or a per-team board), this will require either a workflow edit or a fork. Worth keeping in mind, not worth changing now.

3.2 Observation — Coexistence with the native Auto-add rule

The previous PR (#11) introduced the org-level native Auto-add rule and removed this workflow. This PR restores the workflow but does not say whether the native rule is also being kept. If both run in parallel after the 8 caller workflows land, actions/add-to-project is idempotent so there's no correctness bug, but Actions minutes are spent on what the native rule would have done for free. Worth deciding (and noting in the rollout plan) whether the native rule will be disabled once the reusable-workflow path is wired up across sub-repos. This is a process / rollout note, not a change request on this PR.

4. Recommendation

Approve. The YAML is correct, the security-sensitive pull_request_target path is properly contained, the SHA pin is verified, and every prior-review concern is resolved with documentation that survives in the source rather than only in the PR thread.